home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 20 / Cream of the Crop 20 (Terry Blount) (1996).iso / comm / nwrth210.zip / RFC1036.TXT < prev    next >
Text File  |  1994-04-03  |  46KB  |  1,067 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          M. Horton
  8. Request for Comments:  1036                       AT&T Bell Laboratories
  9. Obsoletes: RFC-850                                              R. Adams
  10.                                               Center for Seismic Studies
  11.                                                            December 1987
  12.  
  13.  
  14.               Standard for Interchange of USENET Messages
  15.  
  16.  
  17.  
  18. STATUS OF THIS MEMO
  19.  
  20.     This document defines the standard format for the interchange of
  21.     network News messages among USENET hosts.  It updates and replaces
  22.     RFC-850, reflecting version B2.11 of the News program.  This memo is
  23.     disributed as an RFC to make this information easily accessible to
  24.     the Internet community.  It does not specify an Internet standard.
  25.     Distribution of this memo is unlimited.
  26.  
  27. 1.  Introduction
  28.  
  29.     This document defines the standard format for the interchange of
  30.     network News messages among USENET hosts.  It describes the format
  31.     for messages themselves and gives partial standards for transmission
  32.     of news.  The news transmission is not entirely in order to give a
  33.     good deal of flexibility to the hosts to choose transmission
  34.     hardware and software, to batch news, and so on.
  35.  
  36.     There are five sections to this document.  Section two defines the
  37.     format.  Section three defines the valid control messages.  Section
  38.     four specifies some valid transmission methods.  Section five
  39.     describes the overall news propagation algorithm.
  40.  
  41. 2.  Message Format
  42.  
  43.     The primary consideration in choosing a message format is that it
  44.     fit in with existing tools as well as possible.  Existing tools
  45.     include implementations of both mail and news.  (The notesfiles
  46.     system from the University of Illinois is considered a news
  47.     implementation.)  A standard format for mail messages has existed
  48.     for many years on the Internet, and this format meets most of the
  49.     needs of USENET.  Since the Internet format is extensible,
  50.     extensions to meet the additional needs of USENET are easily made
  51.     within the Internet standard.  Therefore, the rule is adopted that
  52.     all USENET news messages must be formatted as valid Internet mail
  53.     messages, according to the Internet standard RFC-822.  The USENET
  54.     News standard is more restrictive than the Internet standard,
  55.  
  56.  
  57.  
  58. Horton & Adams                                                  [Page 1]
  59.  
  60. RFC 1036              Standard for USENET Messages         December 1987
  61.  
  62.  
  63.     placing additional requirements on each message and forbidding use
  64.     of certain Internet features.  However, it should always be possible
  65.     to use a tool expecting an Internet message to process a news
  66.     message.  In any situation where this standard conflicts with the
  67.     Internet standard, RFC-822 should be considered correct and this
  68.     standard in error.
  69.  
  70.     Here is an example USENET message to illustrate the fields.
  71.  
  72.               From: jerry@eagle.ATT.COM (Jerry Schwarz)
  73.               Path: cbosgd!mhuxj!mhuxt!eagle!jerry
  74.               Newsgroups: news.announce
  75.               Subject: Usenet Etiquette -- Please Read
  76.               Message-ID: <642@eagle.ATT.COM>
  77.               Date: Fri, 19 Nov 82 16:14:55 GMT
  78.               Followup-To: news.misc
  79.               Expires: Sat, 1 Jan 83 00:00:00 -0500
  80.               Organization: AT&T Bell Laboratories, Murray Hill
  81.  
  82.               The body of the message comes here, after a blank line.
  83.  
  84.       Here is an example of a message in the old format (before the
  85.       existence of this standard). It is recommended that
  86.       implementations also accept messages in this format to ease upward
  87.       conversion.
  88.  
  89.                From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
  90.                Newsgroups: news.misc
  91.                Title: Usenet Etiquette -- Please Read
  92.                Article-I.D.: eagle.642
  93.                Posted: Fri Nov 19 16:14:55 1982
  94.                Received: Fri Nov 19 16:59:30 1982
  95.                Expires: Mon Jan 1 00:00:00 1990
  96.  
  97.                The body of the message comes here, after a blank line.
  98.  
  99.       Some news systems transmit news in the A format, which looks like
  100.       this:
  101.  
  102.                 Aeagle.642
  103.                 news.misc
  104.                 cbosgd!mhuxj!mhuxt!eagle!jerry
  105.                 Fri Nov 19 16:14:55 1982
  106.                 Usenet Etiquette - Please Read
  107.                 The body of the message comes here, with no blank line.
  108.  
  109.     A standard USENET message consists of several header lines, followed
  110.     by a blank line, followed by the body of the message.  Each header
  111.  
  112.  
  113.  
  114. Horton & Adams                                                  [Page 2]
  115.  
  116. RFC 1036              Standard for USENET Messages         December 1987
  117.  
  118.  
  119.     line consist of a keyword, a colon, a blank, and some additional
  120.     information.  This is a subset of the Internet standard, simplified
  121.     to allow simpler software to handle it.  The "From" line may
  122.     optionally include a full name, in the format above, or use the
  123.     Internet angle bracket syntax.  To keep the implementations simple,
  124.     other formats (for example, with part of the machine address after
  125.     the close parenthesis) are not allowed.  The Internet convention of
  126.     continuation header lines (beginning with a blank or tab) is
  127.     allowed.
  128.  
  129.     Certain headers are required, and certain other headers are
  130.     optional.  Any unrecognized headers are allowed, and will be passed
  131.     through unchanged.  The required header lines are "From", "Date",
  132.     "Newsgroups", "Subject", "Message-ID", and "Path".  The optional
  133.     header lines are "Followup-To", "Expires", "Reply-To", "Sender",
  134.     "References", "Control", "Distribution", "Keywords", "Summary",
  135.     "Approved", "Lines", "Xref", and "Organization".  Each of these
  136.     header lines will be described below.
  137.  
  138. 2.1.  Required Header lines
  139.  
  140. 2.1.1.  From
  141.  
  142.     The "From" line contains the electronic mailing address of the
  143.     person who sent the message, in the Internet syntax.  It may
  144.     optionally also contain the full name of the person, in parentheses,
  145.     after the electronic address.  The electronic address is the same as
  146.     the entity responsible for originating the message, unless the
  147.     "Sender" header is present, in which case the "From" header might
  148.     not be verified.  Note that in all host and domain names, upper and
  149.     lower case are considered the same, thus "mark@cbosgd.ATT.COM",
  150.     "mark@cbosgd.att.com", and "mark@CBosgD.ATt.COm" are all equivalent.
  151.     User names may or may not be case sensitive, for example,
  152.     "Billy@cbosgd.ATT.COM" might be different from
  153.     "BillY@cbosgd.ATT.COM".  Programs should avoid changing the case of
  154.     electronic addresses when forwarding news or mail.
  155.  
  156.     RFC-822 specifies that all text in parentheses is to be interpreted
  157.     as a comment.  It is common in Internet mail to place the full name
  158.     of the user in a comment at the end of the "From" line.  This
  159.     standard specifies a more rigid syntax.  The full name is not
  160.     considered a comment, but an optional part of the header line.
  161.     Either the full name is omitted, or it appears in parentheses after
  162.     the electronic address of the person posting the message, or it
  163.     appears before an electronic address which is enclosed in angle
  164.     brackets.  Thus, the three permissible forms are:
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Horton & Adams                                                  [Page 3]
  171.  
  172. RFC 1036              Standard for USENET Messages         December 1987
  173.  
  174.  
  175.               From: mark@cbosgd.ATT.COM
  176.               From: mark@cbosgd.ATT.COM (Mark Horton)
  177.               From: Mark Horton <mark@cbosgd.ATT.COM>
  178.  
  179.     Full names may contain any printing ASCII characters from space
  180.     through tilde, except that they may not contain "(" (left
  181.     parenthesis), ")" (right parenthesis), "<" (left angle bracket), or
  182.     ">" (right angle bracket).  Additional restrictions may be placed on
  183.     full names by the mail standard, in particular, the characters ","
  184.     (comma), ":" (colon), "@" (at), "!" (bang), "/" (slash), "="
  185.     (equal), and ";" (semicolon) are inadvisable in full names.
  186.  
  187. 2.1.2.  Date
  188.  
  189.     The "Date" line